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Abstract 

At the time when the IPv6 specifications were written, the IPv6 flow 
label was still experimental, and subject to change, as the 
requirements for flow support in the Internet were evolving. 

The last several years of work in IETF on internet Protocols Quality 
of Service (Intserv, and Diffserv) and Multi- Protocol Label Switching 
(MPLS) provide a more solid and ample architectural perspective, and 
framework for the standardization of the IPv6 flow label. The new 
charter of the IPv6 Working Group invites contributions to this 
standardization. 

This memo provides an analysis of the IPv6 definition of the flow 
label, the rules governing its use, and their implications. It 
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subsequently makes a proposal for additions/modifications to these 
rules, which improve the usability of the IPv6 flow label, in 
particular with Diffserv, and its acceptance as a standard mechanism. 
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l . introduction 



A* atated by (IPv6) , at the time when the TPvfi specif ication© were 
written, the IPv6 flow label was still experimental, and subject to 
change, as the requirements for flow support in the Internet were 
evolving . 

The last several years of work in IETF on Internet Protocols Quality 
of Service (Intserv, and Diffserv) and Multi- Protocol Label Switching 
(MPLS) provide a more solid and ample architectural perspective, and 
framework for the standardization of the IPv6 flow label. The new 
charter of the IPv6 Working Group invites contributions to this 
standardization. 

Note: The IETF work on Intserv, Diffserv, MPLS is documented in several 
specifications, among which the architecture documents [Intserv] , 
[Diffserv) , and respectively (MPLS-Arch) . Intserv and Diffserv present 
two alternative solutions to resolving QoS problems in the Internet, 
while MPLS is a technology based on labeling traffic flows. 

The IPv6 flow label is a function that, as it was designed, can be 
used towatdw * more efficient proceeding of packet* ixi next hop 
lookup, quality of service, or packet filtering engines in IPv6 
forwarding devices . These devices would normally be IPv6 routers or 
switches. However, the current IPv6 flow label definition and 
specification can be further clarified or even improved, in 
particular in regards to Differentiated Services Quality of Service 
(Diffserv) . 

Diffserv seems to have more potential, and could be used more 
extensively than originally thought. Por instance, for IP QoS xn 
access networks, Diffserv could be used on individual flows of 
traffic between users and the access networks. The nature of the 
contractual agreements between the users and the access network 
providers seem to create an environment in which Diffserv with 
Multi-Field (M-F) classifiers could be easier to use, more efficient, 
and more practical ao an alternative to Intserv and RSVP. 

However, the Diffserv M-F classifiers, the 5 or 6 element tuple, 
containing host-to-host protocol id, and source and destination 
ports, is a bit of a problem When packeto have extcnoion headers 
(IPv4 or IPv6) . In IPv6, that is even more of an efficiency problem 
(need' for sequential inspection), since extension headers have a much 
wider and frequent use. 

The IPv6 flow label, and the use of IPv6 flow label classifiers would 
be a big help in alleviating this problem. An IPv6 flow label 
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classifier is basically a 3 element tuple - source and destination 
IPv6 addresses, and the IPv6 flow label (Diffserv- Plow- Label) . It is 
an alternative to the 5 element tuple (addresses, ports, and 
protocol). It will help the IPv6 flow label to achieve, as xt is 
supposed, a more efficient processing of packets in quality of 
service engines in IPv6 forwarding devices. 

This specification provides an analysis ot the definition of the IPv6 
flow label [IPv6], the rules governing its use, and attempts to make 
clarifications to their implications. It subsequently suggests some 
additions, or modifications to these rules, which in the view of the 
authors, improve the usability of the IPv6 flow label, in particular 
with Diffserv, and its acceptance as a standard mechanism. 

The keywords MUST. MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 
defined in (KEYWORDS] . 



2. IPv6 Flows 

A flow is a sequence of packets sent from a particular source, and a 
particular application runnluy on the source hoot, uoing a particular 
host-to-host protocol for the transmission of data over the Internet, 
to a particular (unicast or multicast) destination, and particular 
application running on the destination host, or hosts, with a certain 
set of traffic, and quality of service requirements. 



3 Other Definitions of Flows 

As IPv6 relies on Quality of Service Mechanisms defined by the 
integrated Services Architecture or the Differentiated Services 
Quality of Service Architecture, it is worth considering those 
architectures flow definitions. The MPLS architecture also defines a 
technique of labeling flows worth considering. 



3.1 Integrated Services Flows 

The Integrated Services architecture [Intserv] defines a flow as an 
abstraction which is a distinguishable stream o£ related datagrams 
that results from a single user activity and requires the same QoS. 
For example, a flow might consist of one transport connection or one 
video stream between a given host pair. It is the finest granularity 
of packet stream distinguishable by the Integrated services. 

Furthermore, the Integrated Services architecture [Intserv) defines a 
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classifier: 

Por the purpose of traffic control (and accounting) , each incoming 
packet must be mapped into some class; all pacers in the same 
class get the same treatment from the packet scheduler. This 
mapping is performed by the classifier. Choice of a class may be 
based upon the contents of the existing packet header (s) and/or 
some additional classification number added to each pocket. 

a class might correspond to a broad category of flows, e.g., all 
video flows or all flows attributable to a particular organization. 
On the other hand, a class might hold only a single flow. A class 
is an abstraction that may be local to a particular router; the 
same packet may be classified differently by different routers 
along the path. For example, backbone routers may choose to map 
many flows into a few aggregated classes, while routers nearer the 
periphery, where there is much less aggregation, may use a separate 
class for each flow. 

3,2 Differentiated Services Plows 

The Differentiated Services architecture [Diffoerv] define© a flow or 

microflow as a single instance of an application-to-application flow 
of packets, which is identified by the source address, source port, 
destination address, destination port and protocol id (fields in the 
IP and host-to-host protocol headers) . 

Furthermore, this architecture defines a classifier as: 

a mechanism that selects packets in a traffic stream based on the 
content of some portions of the packet header. Two types of 
classifiers are defined. The BA (Behavior Aggregate) Classifier 
classifies packets based on the DS codepoint only. The MP (Multi- 
Pield) classifier [Diff serv-Model] selects packets based on the 
value of a combination of one or more header fields, such as source 
address, destination address, DS field, protocol ID, source port 
<uid aeetinetion port numbers, and other information such as 
incoming interface. 

Classifiers are used to "steer" packets matching some specified 
rule to an element of a traffic conditioner for further procoooxng. 
Classifiers must be configured by some management procedure in 
accordance with the appropriate TCA. 

Note- For the purpose of this document, only a portion of the 
definition of the classifier from the architecture IDiffserv) is 
mentioned. 
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3.3 MPLS Flows 

As it travels from its source to its final destination, an IP packet 
is being forwarded from one router to the next, each router making an 
independent forwarding decision (next hop) based on the packet's IP 
header, and routing information processed and stored. Choosing the 
next hop can be thought of as the composition of two functions . The 
first function partitions the entire set of possible packets into a 
set of "Forwarding Equivalence Classes (FECs)» [MPLS -Arch] . The 
second maps each FEC to a next hop. Insofar as the forwarding 
decision is concerned, different packets, which get mapped into the 
same FEC, are indistinguishable. All packets, which belong to a 
particular PEC, and which travel from a particular node, wxll follow 
the same path (or if certain kinds of multi-path routing are in use, 
they will all follow one of a set of paths associated with the FEC) . 
in MPLS, the assignment of a particular packet to a particular FEC 
results in a label being associated to that FEC. When a packet is 
forwarded to its next hop, the label is sent along with it; that is, 
Che packets are -labeled" before they are forwarded . Once a packet is 
labeled, at subsequent bops, the forwarding is done based on the MPLS 
label rather than the information in the IP header. The label xs used 
as an index into a table which specifies the next hop, and a new 
label. The old label is replaced with the new label, And the pocket 
is forwarded to its next hop. 

4. IPv6 Flow Label 

The IPv6 Flow Label is defined HPv6) as a 20 bit field in the IPv6 
header which may be used by a source to label sequences of packets 
for which it requests special handling by the IPv6 routers, such as 
non-default quality of service or "real-time" service. According to 
(IPv6) , the nature of that special handling might be conveyed to the 
routere by a control protocol. »uch as a resource reservation 
protocol, or by information within the flow's packets themselves, 
e.g., in a hop-by-hop option. 

The characteristics of IPv6 flows and flow labola, or the rule* that 
govern the flow label functions are further defined in [IPv6] . For 
the purpose of this document the text from one paragraph in [IPv6] 
was rearranged as an item list, as follows: 

(a) A flow is uniquely identified by the combination of a source 
address and a non-zero flow label. 



(b) 



Packets that do not belong to a flow carry a flow label of zero. 
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(c) A flow label is assigned to a flow by the flow's source node. 

<<!> New flow labclo muot be choson (pseudo- ) randomly and uniformly 
from the range 1 to FFPFP hex. The purpose of the random 
allocation is to make any set of bits within the Plow Label 
field suitable for use as a hash key by routers, for looking up 
the state associated with the How. 



(e) All packets belonging to the same flow must be sent with the 
same source address, destination address, and flow label. 

(f ) if packets of a flow include a Hop-by-Hop Options header, then 
they all must be originated with the same Hop-by-Hop Options 
header contents (excluding the Next Header field of the Hop-by- 
Hop Options header) . 



(g) If packets of a flow include a Routing header, then they all 
must be originated with the same contents in all extension 
Headers up to and including the Routing hoador Excluding th 
Next Header field in the Routing header). 



(h) The routers or destinations are permitted, but not required, t< 
verify that these conditions are satisfied. If a violation is 
detected, it should be reported to the source by an ICMP 
Parameter Problem message, Code 0, pointing to the high-order 
octet of the Plow Label field (i.e., offset 1 within the IPv6 
packet) . 



(i) The maximum lifetime of any flow-handling state established 

along a flow's path must be specified as part of the description 
of the state-establishment mechanism, e.g., the resource 
reservation protocol or tho £low-cotup hop-by- hop option. 



A source must not reuse a flow label for a new flow within the 
maximum lifetime of any flow-handling state that might have bo< 
established for the prior use of that flow label. When a node 
stops and restarts (e.g., as a result of a "crash"), it must t* 
careful not to use a flow label that it might have used for an 
earlier flow whose lifetime may not have expired yet. 
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5. IPv6 Plow and Flow Label Discussion 

This section is going to discuss several aspects of the flow label, 
which are tne target or deifications or improvoment. 

5.1 Plow Label processing by Integrated Services Routers 

The Integrated Services traffic classification based on flow label in 
conjunction with the use of the Resource Reservation Protocols (RSVP) 
for propagating the flow label value seem to be in synchronism. Thas 
topic does not require further discussion. 

The capability to specify a filter based on source, and destination 
addreeseu, and flow label presents the advantage of having all the 
filtering elements in one header, as opposed to multiple headers. 

5.2 Plow Label processing by Differentiated Services Routers 

At the time of the writing of this document, the Differentiated 
services architecture definition of classifiers (Diffserv) does not 
seem to include, nor to exclude explicitly the classification of IPv6 
packets based on flow labels. The definition in (Dif f eerv-Modcl) io 
general enough to invite the use of the flow label. 

in order to support the Flow Label, a Differentiated Services IPv6 
classifier definition should be added. This class ifier would^ be a 
multi-field classifier, which would include as classification fields 
at least the flow label, and the source address, as the IPv6 
B peeific»ti*n I IPv6) suggests. To allow and use a wild card source 
address is perhaps debatable. The MP classifier could be extended 
with the destination address, so it would.be a 3 element tuple: 
source and destination addresses, and flow label. Range of addressee, 
or range of flow labels may be specified. 

The definition of a MP classifier based on source, and destination 
addresses, and flow label presents the advantage of having a " Jhe 
classification elements in one packet header, ao opposed to 
in one packet -s multiple headers, that is, the IPv6 main header, and 
transport (or host-to-host) header. 

According to the Differentiated services architecture (Diffserv) the 
classification fields have values according to the Service Level 
Agreemnts (SALs). and Traffic Conditioning Agreements (TCAs) , 
(iervice Level Specifications - SLSs. and Traffic J^^JfS 
specifications - TCSs) which are contractual agreements between 
network clients and network service providers. The flow label based 
Diffeerv MP classifier would follow the same model, and would rely on 
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the flow label which is a field with a value or range of values on 
which clients and service providers would have to agree on. That 
value, or value ranges of the flow labels would be reflected in SUVs, 

TCAtt, SI*Ss, and TC3e . 

A© the Diffserv classifier fields are known a priori, before traffic 
is being generated by a source of packets, the same should apply to 
the flow label classifier ana the flow label value- This ie 
contradicted by a random generation of the flow label value. In order 
to resolve this contradiction, rule marked (d) in Section 4, 
extracted from [IPv6] , Appendix A, which states that the flow label 
should be pseudo- random, must be relaxed or removed (a subsequent 
section is a summary of proposals) . 



5.3 Plow Label based Piltering 

A similar problem as the Multi-Field classifier contradiction 
described in the oootion above occurra wH.r.h any type of filtering that 
a forwarding engine may have to perform, in which the filtering rules 
are configured by a network manager, or are loaded in the forwarding 
engine by methods other than a resource reservation protocol, or hop 
by hop signaling. Note that the filtering may havo juot internal 
purposes to a forwarding engine, or to a router (which is assumed may 
have several forwarding engines), or to a segment of the network, or 
to a network. In all of the cases enumerated above, the expectation, 
or assumption is that the IPv6 header carries in its fields a net of 
predictable, or well determined values. This is not the case, if the 
flow label has a randomly chosen value. 

This problem of not being able to configure or load filtering rules, 
which are based or are including the flow label, can be resolved 
simply by relaxing or removing the rule marked (d) in Section 4, 
extracted from [IPv6) , Appendix A. which is that the flow label must 
be a random number. 



5.4 Bnd-Lo-eixd/Hop-by-hop uoc of the IPv€ Plow Label 

The definition in [IPv6] gives a definite hop-by-hop characteristic 
to the flow label. The flow label is supposed to help the routing 
system in processing packets whether during packet forwarding, or 
whether during QoS processing. However, controversial discussion took 
place around the end-to-end use and character of the flow label. 

For instance it was stated that the label sbould be used as a 
mechanism for identifying a flow by the destination end-node. Such 
statements seem to be warranted by the use of the IPv6 pair of source 
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and destination addresses as component fields in host-to-host 
connection (virtual circuit oriented communication) or communicatipn 
(connectionless oriented) identifiers, and thus the flow label would 
just be an addition or a replacement to ouch ident i f However, if 
the routers' packet processing is more performance critical then 
end-nodes 1 processing, as the author of this document believes, it 
would seem to make more sense to use the flow label for that purpose, 
that is to use the flow label hop-by-nop significance. 

Using a flow label end-to-end or hop-by-hop seem to be fine in the 
context of the current definition of the flow label, as long as the 
non-mutable character of the flow label is maintained. The issue of 
mutable or non-mutable is going to be discussed in a separate 
section. 

The discussion around the end-to-end, or hop-by-hop use of a flow 
label becomes irrelevant if a certain negotiation mechanism amongst 
routers and end-nodes takes place. There are examples of technologies 
in which such nesotiationo around flow labels and flows labeling take 
place For instance the Label Distribution Protocol of MPLS [MPLS- 
LDP] is used to exchange labels among neighboring MPLS Routers, 
including the source and the destination of the labeled packets. 
Furthermore, the Resource Reservation Protocol (RSVP) (RSVP) hao been 
extended [RSVP-TE] to exchange labels between neighboring label 
switch (MPLS) routers. But such a mechanism, at the time of writing 
this specification, does not exist for IPv6 flow labels, or as Part 
of the IPv6 set of specifications. However, such a mechanism could be 
specified in the future, therefore the specification or the 
definition of the IPv6 flow label should not restrict the use of the 
flow label in one way or another relative to its end-to-end or hop- 
by- hop characteristic. 

In conclusion, the flow label could have a bivalent character in the 
t ypo of ifce usage, or in its significance: 

(i) end-to-end, and 
(li) hop -by -hop. 

The end- to- end significance should not preclude ite hop-by-hop 
significance, and vice-versa. If a node which sends packets, 
associates a certain end-to-end significance to the flow label of 
those packets, that significance can be meaningful also hop-by-hop to 
each downstream router, all the way to the final destination. 
Furthermore, the flow label could be changed in the packet headers by 
the en-route routers, and restored or not to its original value by 
the last hop router, as long as the end-node is aware of what the 
value of the flow label should be. Certainly such a behavior would 
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need negotiation and state storing in the en-route routers, in 
particular the last hop one. 

5.5 Mutable/Non-mutable IPv6 Plow Label 

Another topic of controversial discussion is whether the flow label 
should be mutable or non-mutable, tfcat is it should be read-only for 
routers or not. 

Statements that advocate a non-mutable characteristic are certainly 
based on the advantage of the simplicity implied by sucn a 
characteristic. 

opposite statements, that the flow label should be mutable, are based 
on the flexibility that this provides, in particular if the label has 
a hop-by-hop significance. However, using mutable flow labels would 
not work without a certain agreement, or negotiation between 

neighboring nodco (routers) , or certain configuration of those 
routers. This would require the use of a negotiation mechanism 
between neighboring routers, or a certain setup through router 
management or configuration, to make sure that the values or the 
changes maae to tne now label are known to all routero on tha 
portion of the path of the packet, in which the flow label changes, 
some of these mechanisms, such as MPLS Label Distribution Protocol 
[MPLS-LDP], or RSVP extensions for Traffic Engineering [RSVP-TBJ, 
were briefly mentioned in the previous section, such a mechanism 
could be specified for IPv6 flow labels. 

As the hop-by-hop significance of the flow label can be enhanced by a 
mutable characteristic, the specification or definition of the tlow 
label should not preclude this. 

A mutable flow label though requires the relaxation or elimination of 
the rules marked (a), (c) , (d) , and <j> in Section 4. These rules 
were extracted from [IPv6) , Appendix A. 

5.6 Using Random Numbers in setting the IPv6 Plow Label 

The rule marked (d) in Section 4, extracted from [IPv6), Appendix A, 
specifies the requirement of pseudo- randomness in setting the value 
of a flow label. The reason given is the use of a hashing function, 
and hashing table for flow lookup by routers. Randomness certainly 
helps if the flow label is the only criterion used in the flow 
lookup . 

The use of a hashing mechanism is one possible choice for the flow 
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lookup in routers, or hosts. 

Another possible choice is to use the label as an index in an array, 
which 18 a direct and faster lookup, or retrieval of the flow State, 
and so a contiguous set of values, starting from 1, would be more 
helpful, in particular if the flow label is not the only criterion 
used. 

However, the authors of this document believe that the specification 
of the flow label should not mandate any implementation choices, 
whether they are random values, with hashing functions, or just 
contiguous values, with array indexing. 

Furthermore, a random value in the header is introducing the 
unpredictability of the field. Although this may be an argument of 
philosophical nature, predictability is a necessary condition for 
deterministic behavior. Deterministic behavior is a MUST in a 
network. Network operators may require that P^"* ^f^.Jf"? 
always the oame IPv6 content. Random values in the IPv6 flow label 
certainly break such a requirement. 

To resolve these issues would certainly require the relaxation or 
elimination of rule marked (d) , in Section 4, extracted from Appendix 
A Of [IPv6] . 

5.7 IPv6 Multi-Field Classifiers Efficiency 

This section will address multi-field classification engines 
ftfficiency issues. 

5.7.1 Classification Rules Memory Requirements 

When the flow label value is completely independent from host-to-host 
protocol id and source and destination port information the 
classification rules that contain MF flow label classifiers are at 

least partially independent from the elacoif ication rules that 

contain regular MF classifiers. If somewhat the flow label could 
capture the port and host-to-host protocol information, then the flow 
label classifier values could be in their entirety inferred from a 
regular M-F classifier values. This could help in otorxng 
classification rules in encoding, and perhaps aggregating information 
in ways in which memory consumption could be minimized. However, the 
issue and the gain could be categorized as minor. 
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5.7.2 Pipe-Lined or Parallel Processing Classification. 

As it was stated above, an IPv4 QoS multi-field classification 
engine, perrorms a lookup of 3 or 6 field© of the ip and H©*t -to-hoRt 
protocol headers, in the classification rules table. As most of the 
time, these headers are back to back (contiguous), the position of 
the fields is well-known, and therefore the processing can be 
pipelined or parallelized efficiently, certainly, the existence of 
one or more IPv4 security headers, disturbs the contiguity of the 
headers, but as an encrypted packet would have the host-to-hpst 
header encrypted, it is likely that its fields would not be part of a 
classification rule for that packet's flow. 

In IPv6 , in case of a Multi-Field Classifier, the IPv6 extension 
header© that are potentially located between the IPv6 header and the 
host-to-host protocol header, need to be processed secjuentially, 
before having access to the host-to-host protocol id, and the host- 
to-host source and destination ports. This adds a certain degree of 
difficulty ia designing a pipelining or parallel profaning 
mechanism. The use of the flow label as a replacement of the host - 
by-host fields (source and destination ports and protocol xd) in the 
classification rules certainly alleviates this issue. Furthermore, 
the use of the flow label, relaxes the Issue mentioned prcviouely 
with security headers. 

6. Summary of Proposals for the IPv6 Plow Label 

In summary, the following are the actions being proposed: 

1. For the Differentiated Services M-F Classification rules to 
include the IPv6 flow label classifer: 

<i) write a document that define* a flow label based classifier. This 
is going to be a separate document, a Differentiated services 
specification. 

(ii) Maice a Slight chanye to the flow label definition, by introducing 
the Diffserv flow label format. 

(iii) Rules in Appendix A of (IPv6), do not apply to Diffserv IPv6 
flow labels. 

2. For the Diffserv IPv6 flow labels: 

(i) Redefine characteristics or rules (a), (b) , (c) , (i) , CJ) for 
Diffserv IPv6 Flow Labels. 
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(ii) Remove characteristics (e) , (f), (g) for Diffserv IPv6 flow 
labels. They prevent certain ways of aggregating flows into one flow. 

The following section, contains cue text ttoat ayecifieo the newly 
suqqested IPv6 flow label definition and rules. They would apply to 
Diffserv flows, and to the use of flow label based non-QoS filtering. 
They could also apply to Intserv flows, since there is no technical 
reason that would prevent that. 



IPv6 Flow Label Definition and Characteristics 

The IPv6 Plow Label is a 20 bit field in the IPv6 header which may be 
used to label packets of the same packet flow, or aggregation of 
flows This labeling con be uoed by IPv6 Quality of Service engines 
in routers, for packet classification, policing, and scheduling. It 
can also be used by IPv6 filtering engines in routers, that use 
filtering for various purposes. Documenting such filtering purposes 
is beyond tne scope ot tnis douuraeut. 

The flow label values can be communicated to routers through a 
resource reservation protocol, by a flow label distribution protocol, 
or by information within the flow's packets themselves, e.g., lu a 
hop-by-hop option. They can also be configured in routers, manually, 
or by ways of some automated procedures, or simply uploaded through 
management or policy control procedures. 

The characteristics of IPv6 flows and flow labels are further defined 

as: 



(a) A flow is uniquely identified by the combination of source 
address, destination addrooo and a non-zero flow label. Diffserv 
flows MAY be aggregated by specifying a range of addresses 
and/or a range of flow labels (see further in (e)> . 

(b) A flow label of zero means that the flow label has no 
significance, the field is unused, and therefore has no effect 
on, or for the packet processing by forwarding, QOS, or 
filtering engines. 



( C ) a flow label is assigned to a flow by the flow's source node. It 
can be changed en-route, with the condition that its original 
significance be maintained, or restored, when necessary. For 
instance if the source of the flow intended that the flow label 
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has a certain significance to the destination end-node, than the 
nodes en- route, that process and eventually change the value of 
the flow label, should make sure, in conjunction with the 
destination end-node, that even when the value or eignif ie«nee 
has changed en-route, the original information and significance 
is restored when or before the packet arrives to its 
destination. 

If the action to be performed on a particular flow label is not 
known, a router MOST not change the value of that flow label . 



<d) The flow label must have a value between 1 and PPPFP in hex. It 
identifies a flow. It is a preset value. No particular method is 
preferred for choosing the value. However, the value MUST 
satisfy the following requirements: 

(i) It can be communicated to all routers on the path of the 
flow to the final deotination, as well as the destination node* 
by ways of a resource reservation protocol, a flow label 
distribution protocol, a signaling mechanism, or by any other 
means. The first method is typical for the Integrated Services 
model . 

(ii) It can be configrured, uploaded, or transmitted to a router 
or a group of routers in any other possible way, as long as it 
can be stored in the classification rules tables or the 
forwarding engines of routers along the path of the flow to the 
final destination. If the flow label is used within a 
Differentiated Services framework, the values of the flow labels 
are preset or agreed upon, and specified in a Service Level 
Agreement (SLA) , Service Level specification (SLS), Traffic 
Conditioning Agreement (TCA) , or Traffic Conditioning 
Specification (tcs) [nif fserv] . This model is typical of 
Differentiated Services. 



(e) in general, all packets belonging to the same flow are sent with 
the same source address, destination address, and flow label. 
However, flows can be trunked, or aggregated in macro-flows. The 
flows, members of a macro- flow, may have different source or 
destination addresses. The trunking, or aggregation of flowo i© 
achieved by simply wildcarding some bits or all bits in some of 
the fields of the multi -field classification rules, which 
contain source address, destination address, and flow label. In 
other words range addresses and/or flow labels can be used. 
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(f > The routers or destinations are permitted, but not required, to 
verify that these conditions are satisfied- If a violation is 
. detected, it should be reported to the source by an ICMP 
Parameter Problem message, code 0, pointing to the high-order 
octet of the Plow Label field (i.e., offset l within the IPv6 
packet) . 

(gj The Diffserv flow labels to. not have a time to live rule. 

However, changes to the value of a flow label of a flow, and/ or 
the correspondent flow label classifier values MUST be 
synchronized. When the flow label value of a flow is changed, 
the change must be reflected in the change of the value of the 
flow label in the multi-Field flow label classifier. 



7.1 IPv6 Plow Label Format 

In order to preserve compatibility with the random number method of 
selecting a flow label value defined in IlPv6] , but relax that 
definition to allow a flow label format that would work with 
Diffserv, the following new format of the flow label could be used: 

0 1 

01234567890123456769 
1 0 1 Ps eudo- Random Value | 



0 1 

012345678901234S6789 

+ . + . + . ♦-«. _ + - + -« t .~ + - + - + -4- + _ + + 

|1| Diffserv IPv6 Flow Label | 



7.1.1 Diffserv IPv6 Flow Label Format 

The Diffserv IPv6 Flow Label is a number that is constructed based on 
the Differentiated Services "Per Hop Behavior Identification Code" 
(PHB ID) IPHB ID) : 
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0 1 

01234567890123456789 
+_+-+.+.*-+-+-♦-+-+-.+-+- + -+-+-+- + -+-■•■-+-♦ 
| 1 | per Hop Behavior Xdcnfe . Code | Roe | 



The "Res" bits are reserved. 

Conforming to [PUB ID) , the PHB ID is either directly derived from .a,, 
standard differentiated services code point [DSCP-Def ) , or it is an 
•IANA Assigned Value". In either case, it captures the differentiated 
services treatment intended to be applied to the packet. Online the 
value of the traffic class field, it is not locally mapped and is 
therefore suitable for use in an end to end header field. Although it 
captures lees epeeific information than the port numbers and protocol 
number normally used in an MP classifier, it nevertheless allows for 
MP classification at a differentiated service domain ingress. 

7.1.2 Other Possible IPv6 Plow Label Formats 

There are various other ways in which a Plow Label can be encoded, 
each way with its advantages and dieedvantagee . Several ideas of slow 
label encoding are enumerated in Appendix A. 

7.2 Conceptual Model for Diffserv use of IPv6 Plow Label 

Diffserv can be used in IPv6 access networks for IPv6 QoS of 
individual flows of traffic between users and the access networks. 
The nature of the contractual agreements between t^e « 8 « 8 . an f 
access network providers create an environment in which Diffserv with 
Multi-Field <M-F> classifiers could be easier to use. more efficient, 
and more practical as an alternative to Intserv and RSVP. 

The IPv6 flow label classifier is basically a 3 element tuple - 
source and destination IPv6 addresses, and the IPv6 flow label 
[Uiteserv-Flow-X^belJ . It ie on alternative to tno S element tuple 
(addresses, ports, and protocol). It helps the IPv6 flow label to 
achieve, as it is supposed, a more efficient processing of packets 
in quality of service engines in IPv6 forwarding devices. 

Whether using algorithmic mapping of port numbers and J"*"**- »« 
values, or just a number randomly chosen, the key for the flow label 
to work with Diffserv is that the «flow_label value" or range of 
values MUST be known, and agreed by two sides: the network client ana 
the network provider. The "flow label value- is captured in SLAs 
SLSe, TCAs, TCSs. For the mechanism to work several things have to 
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happen : 



CI. | Packets leaving the client networks carry the correct flow label 
value. This can be achieved in several ways; 



a end-node IPv6 protocol stacks, and/or IPv6 applications can be 
configured with the flow label "value", me now label -value- io 
. set first by an application. If the application has not set a flow 
label "value 0 , then the "value - is set by the protocol stack. The 
default values would be hard-coded in applications and protocol 
stacks, or could result from "algorithmic mapping", if such 
mappings exists. The default value could be zero, in which case the 
flow label would have no significance. According to this model, 
when packete ar« transmitted, end-nodes will force the correct flow 
label in the IPv6 headers of outgoing packets. 

if a. is not TRUE, then 

b the first hop routers would have to force the correct flow 
label on packets leaving the network. To accomplish this role, 
these routers would be configured with MP classifiers. These 
routers would classify Che traffic that ia forwarded downofcroaro 
from, and away from the originating end-nodes. The action 
subsequent to the classification would be to set the correct flow 
label in each packet. Classification on such a router's input, 
line card, or interface would result, for the matching packets, in 
a correct flow label being forced in the IPv6 headers of packets 
when they are transmitted on the output interface or line card. 

while it is likely that "b.» would not be needed, "a." or "b." would 
provide the correct flow label in packets leaving the client's 
network. 

(2 ) Packets coming into the provider network can be policed based on 
flow label. The provider, based on the SIAs, SLSs, TCAs, TCSs 
agreed with the client, confiyures MP classifier© that look lxko. 

C « (SA, SAPrefix, DA, DAPrefix, Flow-Label) 



or 



C« o (SA, SAPrefix, DA, DAPrefix, Flow- label -MimFLow- label -Max) 
Another representation of the classifier for example is: 
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Flow- label -classifier: 

Type: IPv6-3-tuple 

IPv6DestAddrValue : 1:2:3:4:5:6:7:8: :1 

Ipv6Det»CPrefixI*eogth; 128 

IPv6SrcAddrValue: 8 :7 :6 :5 :4 :3 :2 : 1 : :2 

IPv6SrcPrefi30-engtb: 128 

IPv6Plowfcabel : 57 



or 



and 



or 



Plow-label-classifier: 

Type: iPv6-3-tuple 

XPv6DestAddrValue: 1 :2 :3:4 :5:6 :7 : 8 : :1 

IPv6DestPrefixLength: 128 

iPvfifireAddrValue: 8:7:6:5:4:3:2:1: :2 

IPv6SrcPrefixLength: 128 

IPv6FlowLabelMin: 1 

IPv6FlowLabelMax: 57 



Flow-label-classifier: 

Type; lPv6-4-tuple 

IPv6DestAddrValue: 1:2:3:4:5:6:7:8: :1 

IPv6DestPrefixLength: 128 

I Pv6 S r CAddrVal ue : 8 : 7 : 6 : 5 : 4 : 3 : 2 : 1 : : 2 

IPv6SrcPrefixLength: 128 

IPv6FlowLabel : 57 

IPV6DSCP: 28 



Flow- label -classifier : 

Typot IPv6-4-tuple 

IPv6DestAddrValue: 1:2:3:4:5:6:7:8: :1 

IPv6DestPrefixLength: 128 

IPv6SrcAddrValue: 8:7:6:5:4:3:2:1: :2 

XPv65rcPjr«C jba*engfch; 128 

IPv6PlowLabelMin: 1 

IPv6FlowLabelMax: 57 

IPV6DSCP: 28 



The classifiers are configured in the network provider's edge 
routers, etc — 

The classification engines in those routers would match pacKet 
header information to classification rules as follows: 
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Incoming packet header <SA, DA, Flow Label) 
Match 

Classification rules table entry (C or C) 

Prom this step, the Diffserv processing continues the same way as 
any other MP Classifier [Dif f serv-Model) . 



8 . Security Considerations 

This document introduces no new security concerns when the pseudo- 
random flow label format is used. In the case of a diffserv flow 
label, the security concerns are essentially identical to those 
concerning the diffserv field (traffic class) itself, as outlined in 
(DSCP-Def ] , (Diffserv) , and [Dif f erv-Tun] . 

When IPv6 packets are encrypted using BSP Transport or Tunnel Mode 
(IPCeo BSP] , tho port and protocol numbers are hidden, but the flow 
label is not. Thus MP classification remains possible even for 
encrypted traffic. 



9. IANA Considerations 

The IPv6 flow label format specified in this document, is based on 
the Differentiated Services Per Hop behavior identification Code (PIID 
ID), specified in [PHB ID] . The PHB ID can be a IANA assigned number. 
tPHD ID) contains a "IANA Considerations Section", following 
guidelines stated in (CONS) . No additional IANA considerations have 
to be made. 
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Appendix A: Other Possible IPv6 Plow Label Formats 

This section enumerates several ideas, each with its positive and 
negative aspects. 

A possible solution to the issues discussed in section 5.7 is to 
compress or encode the host -to- host header information, and the 
host-to-host protocol type in the flow label value. This Is an 
algorithmic mapping of the port numbers and protocol into the flow 
label . There are several ways in which this could be achieved, but 
only two are suggested in this section. 

Another format mentioned further down in this section is one in whi 
the length of the IPv6 headers helps locating in one step the host- 
to-hoot header for accesaing the port information. 



A.l Server Port Format - Short Format 

A possible solution to the issues discussed in section 5.7 is to 
compress or encode the host-to-host header information, and the 
host-to-host protocol type in the flow label value. This is an 
algorithmic mapping ot the port numbers and protocol into the flow 
label. There are several ways in which this could be achieved, but 
only three are suggested in this section: 

The Server Port Pormat is a format which is based on carrying in 
the flow label the server port number of a client/server 
application/ communication. 

0 l 

01234567890123456789 
| Server Port Number | H-to-H protocol | 

The "Server Port Number" is the port number assigned to the server 
side ot the client/server application. This provided on 
identification of the application, and the type of application, which 
is a quite good indication of the type of QoS characteristics needed 
for the traffic generated or accepted by that application. Obviously 
it does not provide the finer granularity within the use of one 
application on the same end-nodes, that the use of both source and 
destination ports provide. That is, it cannot differentiate among 
multiple instances of the same application running on the same two 
communicating end-nodes. But for Differentiated services purposes, it 
does not seem to really matter, since it is expected that the several 
instances of an application running on the same two end-nodes, would 
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generate or accept traffic which is of same category, class, or 
behavior . 

The reduced number of bits (12 bits out of i«> limit© the value to 
"IANA Well-known ports", that is ports from 1 to 1023, and a subset 
of "IANA registered ports 0 that is, from 1024 to 4095. Registered 
ports have values between 1024 and 65S35 [Assign) . 

The M H - to- H protocol n is the host-to-host protocol identifier 
(Assign), that is, TCP, OTP, etc 

Advantage 

The advantage of this flow label format is that the classification 
rule ia the typical 5 or 6 tuple format of a Diffserv M-P Classifier 
(Dif f serv-Model] , containing the source, and destination addresses, 
the source and destination ports (in which one of the two is 
wildcard), the host to host protocol, and the DSCP field. So no new 
classification rule format la needed, and further, it io poooiblo to 
aggregate parts of the IPv4, and IPv6 classification rules. Note that 
for classifying traffic in both directions, two classification rules 
must be configured. For instance a classification rule for TCP flows 
on port 80, between node A, and node B: 

Source Address; A 
Destination Address:B 
Source Port:* 
Destination Port: BO 
Host-to-Host Protocol 6 (TCP) 

would be used for all traffic outgoing, from any port, to port 80. 

Source Address: A 
Destination Address ;B 
Source Port: 80 
Destination Port:* 
Host-to-Host Protocol 6 (TCP) 

would be used for all traffic outgoing from port 80, to any port. 



A. 2 Server Port Format - Long Format 

Observation: Since TCP, and OTP are the two major host-to-host 
protocols that carry port numbers in their protocol headers, the 
field occupied by the "host-to-hosf protocol could be reduced to 1 
bit, indicating TCP or OTP, as it follows: 
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0 1 

0123456789 0 123456789 
| TCP Server Port Number | Rea |0| 

0 1 

01234567890123456789 

1 UDP Server Port Number | Res |l| 

The "Res" bits are reserved. 

The "TCP Server Port Number" or "UDP Server Port Number is the 16 bit 
port number assigned to the server side of the client/server 
application. 

A. 3 Header Length Format 

Another possible solution to the issues discussed in section 5.7 is 
to store the IPv6 headers length, that is the length of the IPv6 uw»in 
headers and IPv6 extensions headers preceding the host-to-host, or 
transport header. The length of the IPv6 headers in the. flow label 
value would provide the information which a Dif f serv Q0S engine 
classifier could use to locate and fetch the source and. destination 
ports, and apply those, along with the source and destination address 
and the host-to-host protocol from the flow label, to match the 
goured and destination address, the source and destination ports and 
the protocol identifier elements of a Diffserv M-F classifier 
[Dif f serv-Model) . 

o 1 

01234567890123456789 
+ - + - + - + .4.. + - + + + + 

I Length of IPv6 Headers |H-to-H protocol | 



The -Length of the IPv6 Headers" allows also skipping the IPv6 
headers to access directly the host-by-host header for other 
purposes . 

Additionally, this format is useful for classifying packets that are 
not TCP or UDP, and have no source and destination ports. 

With this 12 bit encoding the maximum length of the IPv6 headers that 
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could be represented is 4Kbytee. However, the restriction on headers 
length can be significantly reduced. IPv6 headers are 8byte aligned, 
therefore the length could be represented as the number of 8byte 
chunks occupied l>y the headers, in which case the maximum length 
would be 32Kbytes. 

If all of the above formats would be used, then there are two ways to 
separate this last type of encoding trom tne otner two mentioned 
above: 

(i) always use a signaling mechanism to distribute the flow label 
values, and so the type of the format would be stored as part of the 
flow state. 

(ii) use a bit field to discriminate the formats. Por instance, a two 
bit field could be used to indicate the first, second, or third type 
of format . 

Note: 

The suggestions described in this section are in fact an exploration 
of possible solutions. Bach suggestion has advantages and 
disadvantages. They are Kept in this section at least for recording 
purposes . 
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